Synchronization in a packet-based communication system is typically achieved by exchanging timestamped packets between a master device and a slave device, both of which may be located at the edges of a packet network. The slave device typically implements a clock recovery algorithm that processes the timestamps to yield a signal that is used to control a local oscillator in the slave device.
Examples of synchronization techniques of this type are disclosed in U.S. Patent Application Publication No. 2010/0158051, entitled “Method, Apparatus and System for Frequency Synchronization between Devices Communicating over a Packet Network,” Publication No. 2010/0158183, entitled “Frequency Synchronization Using First and Second Frequency Error Estimators,” Publication No. 2010/0158181, entitled “Frequency Synchronization with Compensation of Phase Error Accumulation Responsive to a Detected Discontinuity,” and Ser. No. 12/885,958, filed Sep. 20, 2010 and entitled “Frequency Synchronization using Clock Recovery Loop with Adaptive Packet Filtering,” all of which are commonly assigned herewith and incorporated by reference herein.
Packet delay variation (PDV) is a dominant source of noise in many packet-based communication systems. One technique for reducing PDV is to utilize a transparent clock feature in switches, routers and other network devices. This feature generally allows a network device to correct timestamps for packet residency time, which is the time a packet spends in the network device due to processing, queuing and other delays. For example, such a feature is supported by the Precision Time Protocol (PTP) described in IEEE Draft P1588/D2.2, “Draft standard for a precision clock synchronization protocol for networked measurement and control systems,” Dec. 2007, which is incorporated by reference herein. This protocol is also commonly referred to as the IEEE 1588v2 protocol. The event messages of the IEEE 1588v2 protocol include SYNC and DELAY_REQUEST messages, and both of these messages provide a field called the correction field.
In the case of the SYNC message, which is sent by the master device to the slave device, the correction field is set to zero when the SYNC message is transmitted by the master device. Each network device in the path traveled by the SYNC message measures the residency time of the message in that device, and adds it to the correction field. When the slave device receives the SYNC message, it subtracts the correction field from an arrival timestamp generated in the slave device to obtain a corrected arrival timestamp.
In the case of the DELAY_REQUEST message, which is sent from the slave device to the master device, the master device copies the correction field as received in the DELAY_REQUEST message into a corresponding DELAY_RESPONSE message that it sends back to the slave device. The slave device can then use the correction field to correct an arrival timestamp which is generated in the master device and also returned to the slave device in the DELAY_RESPONSE message.
One possible implementation of a network device that supports transparent clock functionality is described in J. Han et al., “Practical considerations in the design and implementation of time synchronization systems using IEEE 1588,” IEEE Communications Magazine, vol. 47, no. 11, pp. 164-170, November 2009. Other known transparent clock techniques are disclosed in S. Ilnicki et al., “Performance of Transparent Clock Using Modified Gigabit Interface Converter,” IEEE 1588 Conference, October 2006.
Providing transparent clock functionality in a new network deployment is a straightforward matter in that the network operator can simply select switches, routers and other devices that support the above-noted IEEE 1588v2 protocol feature. However, a significant drawback of conventional practice is that many existing networks do not support transparent clock functionality because at the time of their deployment, either the IEEE 1588v2 protocol did not exist, network devices that supported the IEEE 1588v2 protocol were not readily available, or the network was originally deployed without the intent to use it with the IEEE 1588v2 protocol. In such situations, the network operator will be understandably reluctant to replace the existing network devices due to cost concerns as well as possible service interruptions. Accordingly, the network operator may be forced to accept the inferior level of synchronization performance that can be achieved without transparent clocks.